What is Multi CDN?
With single CDN, the digital content is delivered through one CDN provider. Multi CDN delivers digital content through multiple CDN providers. Using Multi CDN has a lot of advantages such as:
- Availability: Multi CDN minimizes single points of failure by providing other delivery options if a CDN is unavailable.
- Performance: Multi CDN delivers the best performance for all traffic types, in all regions.
- Capacity: By using multiple CDN providers, the content can be delivered by distributing the load.
What is going to happen during the migration?
You have received the new username and password.
We have copied the existing configuration into the current CDN platform. We will and apply it to our Multi CDN platform.
What do I need to do to migrate to Multi CDN?
After we migrate your CDN to our Multi CDN, please perform the following tasks:
- Verify the configuration to ensure that the Multi-CDN responses are correct.
- Change your DNS configuration from the old CNAME endpoint to the new CNAME endpoint. You can find it in the configuration part of the UI.
- If any API integration is in use, for example for invalidations and purges, this integration will need to be updated to reflect the new API standard (see the API documentation).
Please give special attention to the following:
- CDN properties which have expired or invalid SSL certificates are ignored and not migrated.
- Headers that are not part of the standard HTTP response headers (i.e. custom headers) are ignored and not passed through by default. If some headers need to be enabled (for example CORS headers), make sure to pass them through by adding them to the ‘HTTP header caching’ option, or by adding them as a static header to the CDN configuration. If custom headers are already present as static headers, they will be migrated to Multi-CDN.
Where can I find the CNAME to point my DNS record(s) to?
You can find it under Configuration > Distribution Groups > (click ‘edit’ on the relevant configuration) > you will see the populated field ‘CNAME target’. This is the endpoint to CNAME your custom domain(s) to.
Where can I find documentation of the API usage
The API specifications and example responses and requests are available at https://api.cdn.leaseweb.com
How do I login to Multi CDN?
The Multi CDN portal can be accessed via https://portal.cdn.leaseweb.com
Where can I find the missing zones / distributions?
During the migration to Multi CDN, zones that have expired or invalid SSL certificates attached to it are considered obsolete and are not migrated over to the new platform.
How do I enable raw logging to Multi CDN?
You can enable raw login to Multi CDN via the API/UI per distribution, and set the FTP password you want to use. The credentials for the FTP are in the format <distribution ID>:<FTP password>@ftp.logs.leasewebultracdn.com
What and where are my zones or distribution groups?
Zones are called distribution (groups) in the Multi CDN context. You can find them under Configuration > Distribution Groups.
Where are my caching settings (edge settings)?
A distribution has a policy attached which holds all the different caching options under the "Caching Settings" per distribution. Checking the settings and making changes can be done by clicking the "edit" button under "Caching Settings".
Where are my SSL certificates?
SSL certificates are centrally managed via Configuration > Certificates. After uploading a valid certificate they can be attached to a distribution by changing the TLS settings to SNI TLS/SSL and selecting the certificate in the drop down.
How can I purge / invalidate items?
Purging and invalidating cached content can be done via the ‘Invalidate’ option in the UI. You can add URL(s) and submit them to be purged from the cache. For API implementation, please see: https://api.cdn.leaseweb.com.
What is going to happen if I do not do anything?
The content will no longer be distributed after 31-12-2018, as the account in the current CDN platform will be inactive
What is going to happen with my accounts and invoices?
Until 31-12-2018, both accounts will be active (Current CDN and Multi CDN). On the 31-12-2018, the current CDN account will be cancelled. The billing of Multi CDN starts on 01-01-2019.
You received the last invoice for the usage of the current CDN platform on 01-12-2018.
Traffic used in December will be measured but not charged. We keep the right to charge in case of excessive usage of traffic.
What is going to happen with my statistics?
Statistics from current CDN platform cannot be migrated to Multi CDN. We advise to retrieve them before 31-12-2018 from the current CDN platform.
Is traffic measured differently in Multi CDN (compared to current CDN)?
In Multi CDN, we measure and charge both outbound and inbound traffic. Current CDN only does it for outbound traffic.
I’m not seeing my updated file even after sending an invalidation request which as finished:
Browsers (and intermediate proxies, if any) use the set TTL on the asset to determine if the file should be considered to be fresh enough to serve from its local cache or if it needs to fetch it from the CDN again.
The behaviour you are seeing is expected and can be fixed either by lowering the TTL's significantly (so to instruct the browser to not rely on the local cache too long).
The CDN will always honour the TTL as set by the origin unless it is instructed otherwise.
See https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching for more information.
There is a delay in the processing of the invalidation requests:
It can happen that we have a lot of invalidation requests pending across our customers which can impact the processing time as we have limits on the amount of requests we can
send to our vendors.
Generally it is best practice to use versioning so whenever a new file is uploaded, delays with invalidations or issues with browser cache can be mitigated
See https://medium.com/@codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c for more information
Are there limits on the amount of invalidation requests?
Although currently not enforced it is not advised to send more than 75 files per invalidation request and no more than 1 invalidation request per minute. As sending more can have negative affects on the invalidation performance
across our vendor integrations we reserve the right to throttle the requests when excessive amounts of invalidation requests are done.
To ensure direct availability of an updated asset it is generally advised to use versioning / cache-busting techniques.